Subject: Security comments from Denis Pinkas on June 17th

From: "Richard L. Daugherty (8-444-6838)" <[email-masked]>
Date: Thu, 29 Jul 93 16:16:09 EDT

Denis has many good points.  Extracts from Denis' note are prefixed
with a > and my responses follow.

> Comments on document ciw3party
> (Exploitation of distributed security in SNA LU 6.2 conversations)

> General comments

> 1- The document is focused on authentication and thus does not address to
> other major topics: integrity and integrity + confidentiality. It seems as
> important to cover these two aspects.

It is correct that the architecture is focused on authentication and does not
address integrity and confidentiality.  The APPC CRM already provides
for confidentiality, selected via Mode Name.  Given that confidentiality
services exist, APPC passwords are weakly protected, and the end user
password management headaches, I do not agree that it is as important
to do additional work on confidentiality and integrity as it is to make
baseline improvements in the authentication area.

> 2 - The extensions are designed with a single security mechanism in mind:
> DCE 1.0. The extensions should be opened for evolutions of DCE and for other
> security mechanisms. It is expected that the security protocols of DCE 1.1
> will be different from the security protocols of DCE 1.0 and thus evolutions
> need to be possible. In addition it should also be possible to use a
> different security mechanism like Kerberos, Kryptoknight or SESAME.
> Note that the scope says: " The architecture is flexible enough that any
> services could be used to build the security-related fields, as long as the
> information supplied by the originating security service is understood by
> the destination security service".

The full APPC architecture (which has not been published) include the
possibility of adding additional security mechanisms over time.  The
architecture is (hopefully) flexible enough to handle DCE 1.1, Kerberos,
Kryptoknight and SESAME transparent to CPIC.  However, we are currently
only defining a DCE based mechanism.

> 3 - The document mentions the support of ESSI. The relationship between the
> document and the use of ESSI is not straight-forward. At the moment there is
> another set of APIs able to handle very similar functions: they are known as
> GSS-APIs (from IETF) or Base GSS-APIs from X/Open (they will be issued as a
> preliminary specification). Some rational for choosing ESSI and not GSS-APIs
> should be given. Also, GSS-APIs are not yet casted in concrete: minor
> changes could be made if some functions are lacking.

The APPC architecture work was done assuming ESSI as the interface to the
authentication service.  This is not meant to preclude an implementation
from using GSS-API.  The choice of which interface to use is entirely
up to the APPC implementer.

> 4 - There are two main goals: get rid of all passwords sent in the clear
> over a communication line and allow for delegation (proxy) control. The fist
> goal is well addressed while the second is not covered enough: ways are
> lacking to specify how delegation should be handled. A caller must be able
> to specify whether or not the correspondent should be allowed to delegate
> any further; if yes, what kind (i.e. types) of correspondents are eligible
> for delegation, and, with a lower priority, what kind of restrictions can be
> specified.

General delegation (proxy) control is NOT a goal of this architecture work.
That would help explain why it is not covered enough.  The current
draft APPC architecture, states that the delegation ticket is sent.
Any general proxy control would be added to the APPC architecture as a
separate change.

The current delegation is to allow for cascaded allocates to work.

> 5 - Since DCE allows the support of group-memberships, it is questionable
> whether we should allow to make these groups visible to the applications: a
> ticket carries much more than simply an identity. In a generalized way,
> should we allow to select / obtain security privileges (e.g. group-
> membership, clearances) ? If not, what would be the policy: to send all
> privileges (which violates the principle of least privileges) or to send
> only the identity ?

The intent is to transport the current security context/environment,
including group membership.  We expect programs to use the security
services APIs for manipulating privileges.  This way we will not have
to be continually adding security calls to CPI-C.

> Detailed comments

> It is also needed to signal /indicate the security mechanism being used need
> to be added, e.g. to make a difference between Kerberos V4, Kerberos V5, DCE
> 1.0, DCE 1.1, X 509, etc ... A single bit is not sufficient.

The full formats include such an indication of what security mechanism
is supported by a LU (in the BIND, RSP(BIND)).  The security fields
sent with the attach (FMH5) also include an indicator of the
security mechanism.  This was added allow support of additional
mechanisms.

> Comments page by page

> Page 9. The text under the security level SAME assumes that a single
> mechanism is used, which is in contradiction with the goals mentioned in the
> section 1.0.

Actually, the underlying assumption is that all supported mechanisms will
have things which can be viewed as tickets, authenticators, etc.  Any
mechanism which does not will require additional LU 6.2 protocol changes.

> Page 9. The first bullet under the bullet SAME mentions: if the partner
> indicated authenticator required on every attach (how is this indicated ?),
> then send signon list key (what is this ?, is the list protected ?) ...

Exchanged during BIND processing.  The signon list key is a UUID which
is uniquely tied to a single security environment.  It separates the
ambiguous case of two processes running under the same user identity,
but with different active group memberships (or other privilege
difference).

> Page 11. The second sentence at the bottom of the page says: The
> authentication level can be specified in several places ...
> Is it really an authentication level or a security level instead ?

It is really an authentication level.  It is set via the SECURITY parameter
on ALLOCATE or the Set_Conversation_Security_Type call in CPI-C.

> Page 15. Our understanding is that the new bit in BIND is more to request a
> challenge (also called a nonce) so that, if the underlying security
> mechanisms needs it an exchange can be saved. It does not indicate "support
> for the new distributed system features."

Actually the new bit in BIND is used to indicate that the third piece of
information is exchanged.  That information is policy data (eg, the partner
requires an authenticator on every attach) and a list of supported
mechanisms.

> The nonce can or cannot be used. This is security mechanism dependant.

True, however, the only mechanism being defined uses nonces.

> Page 15. The note in 5.3.2. is not fully understandable. Does this means
> that only the ATTACH get the sequence number, not other flow of information
> ? What kind of threat is supposed to be covered here ?

What it means is that every ATTACH gets the sequence number, even the ones
which have no other authentication information.  The sequence number is
used in conjunction with the nonces to prevent re-play attacks.  It flows
on every attach in order to simplify processing.

> Page 16. Using the signed on From List allows to save the sending of a
> ticket in some cases but increases the burden of the management of such
> lists. The question (translating a French proverb) is whether or not "the
> game is worth the candle". Although the ticket is not specially short, it
> can make sense to avoid all the burden. Coordination of LU's add some extra
> protocols which can counter-balance the advantages. Do we have some figures
> about the real advantage to support this ?

It also saves the processor time of processing the ticket.  (DES software
decryption of a couple of hundred byte.)  We do not have any shareable
figures.

> Page 17. More than one security type can be indicated for one target
> principal name. This should be stated more clearly.

Agreed.

> Page 17. On page 11, it is said that the option actually used will be the
> highest specified in any of the places available at the sending side. This
> is in contradiction with the sentence which says that the directory sets a
> default that the application can override.

Your right, it is in contradiction.  I will have a fix in the AP proposal
for September.

> Page 32. Delegation (called here forwarding) as proposed is rather crude.

You're right.

> Some means to handle these cases have to be provided. If this may be agreed
> in principle then we may work out the details of how to handle it.

I would be interested in any proposal you would care to make.  However,
I would expect that the interfaces to restrict the delegation to
be security service interfaces, not APPC/CPIC interfaces.

Rich D.
[email-masked]

PS:  Let's take the rest of the discussion of this to the
ciw-sig-sec mailing list.